A virtual machine is a layer between the physical hardware and one or more operating systems running on that hardware. The virtual machine virtualizes physically available system resources also called virtual hardware, e.g. CPU, memory storage devices, network devices and the like.
First of all the virtual machine provides functionality to run one or more operating systems on one physical hardware, on one machine. These operating systems are called guest operating systems or short guest systems and are independent from each other. These guest systems do not know about other guest systems (compare FIG. 1). To make this possible, the virtual machine has to virtualize all physical hardware resources required by the guest systems. These hardware resources can be CPU, memory, storage devices, network adapters or any other resource in the system. The virtual machine “multiples” these resources. As an example, the system has one physical CPU but each guest system gets its own virtual CPU. Or all guest systems use the same network adapter, but each guest system “thinks” it is the only user of that network adapter.
The virtual machine layer could be either hardware or software. The virtual machine has to distribute or share the available physical system resources. Here the resource management comes into play.
To install a guest operating system, the virtual machine has to provide an empty guest. The system administrator will create such an empty guest by using commands and tools provided with the virtual machine.
While doing this, the system administrator has to specify all system resources that will later be available for the guest operating system. This is an initial resource allocation, done by hand.
The administrator has to decide, which resources are required and sufficient to run the guest operating system in a high-performance way. Usually the hardware resources will not be changed anymore. But in case they have to be changed, then it is a manually change by the administrator and the operating systems have to be rebooted in most cases to make the latest changes known to the guest operating system.
Substantially two problems occur by this proceeding:                1. Each operating system has different hardware requirements, depending on the kind of operating system (Linux, z/OS, VSE, Windows . . . ) and depending on the task, the operating system has to do. For example the installation kernel of a Linux system, which performs the installation and is in fact a small Linux system too, requires 512 MB memory and one CPU, because installation is just data copying and does not need much CPU power, but much temporary memory. Once the Linux is installed properly and the installation kernel is replaced by the real Linux kernel, the Linux system only needs 256 MB memory, but 4 CPUs, because the Linux has CPU-intensive tasks to do.        2. Most days a year the system has all hardware resources it requires. But at some special days (month end, year end) the workload increases dramatically and much more CPU, memory or network bandwidth is required during these workload peaks.        
To manage the different hardware requirements of different operating systems, usually the administrator reads the specific hardware requirements of a special operating system in the corresponding documentation or uses experience values or just uses the try-and error method and tries to run the operating system with minimum hardware requirements and in case this does not work or end in some error messages from the operating system, he increases some resources, e.g. CPU, memory and the like and tries again. Actually the administrator has to find out the hardware resources somehow, e.g. by experience, iterative approach or luck and has to provide them to the operating system using the commands and tools of the virtual machine. In case something changes, as described in the Linux installation example above, the administrator has to change the hardware resources manually.
To manage workload peaks, actually several approaches exist.    a. One approach is to provide all the times all hardware resources to the operating system that may be required at some peak points. In this case the operating system has more than enough resources, even if they are not needed most time of the year. The drawback of this solution is, that the virtual machine has to provide a virtual hardware to the guest system that requires more physical hardware resources than needed most of the time. These physical hardware resources cannot be used for other guest systems. Due to this it is an expensive approach, because less guest systems than possible can run on the virtual machine.    b. A second approach is to provide minimum hardware resources and in case of heavy workload peaks to increase some system resources manually by the administrator. The drawback of this approach is that the administrator has to notice the workload peak and has to be present to change the system resources manually.    c. A third approach is to install or to activate a prepared second operation system during the workload peaks by the administrator. The drawbacks of this approach is, that some resources for the second operating system have to be reserved on the virtual machine and the administrator has to be present to install or activate the second operating system at the time it is needed.    d. There also exists a fourth approach, which adds dynamically other systems that will be activated automatically during workload peaks. This does not require administrator interventions, but the systems to be activated have to be installed and administrated somehow. These are different operating systems and the admin has to make sure the workload takeover is transparent from outside. The drawback of this solution is that it needs some complex management since it makes no sense e.g. to use a different URL to distribute workload from a full web server. And also here, in case the additional backup servers are not within a virtual machine but real servers in a server farm, most of the backup servers that will be activated in workload peaks are idle most of the time.
The drawbacks of the prior art are, that manually intervention of an administrator is needed when installing a guest operating system on a virtual machine. During increased workload, the known approaches either need manually intervention of an administrator or extra resources that will only be used a few times during a year. In case of a manually intervention the problem occurs, that the administrator has to be present at the time his intervention is required and he has to notice the workload peak. If more resources than mostly needed are provided, the problem occurs, that these resources are unused most of the time and cannot be used by other applications or other guest systems. The known approach to activate other guest systems dynamically when required results in a high system management overhead because the additional activated systems have to be transparent. In case there are also some physical servers that could be activated to handle workload peaks they also will be unused resources most of the time. Another point is to keep these backup servers up-to-date regarding to security fixes.